Компания VMware наконец-то обновила свой главный документ о производительности основной платформы виртуализации - "Performance Best Practices for VMware vSphere 6.7". Несколько ранее мы писали о документе "What’s New in Performance - VMware vSphere 6.7", в котором были рассмотрены основные нововведения последней версии продукта в плане производительности, но там было всего 13 страниц, а в этой книге о производительности - аж 88!

Само собой, книга покрывает аспекты не только новой функциональности vSphere 6.7, но и уже давно существующие фичи (с последними обновлениями, конечно). Вот о каких аспектах производительности платформы можно найти информацию в документе:

• Hardware-assisted virtualization
• Storage hardware considerations
• Network hardware considerations
• Memory page sharing
• Getting the best performance with iSCSI and NFS storage
• Getting the best performance from NVMe drives
• vSphere virtual machine encryption recommendations
• Running storage latency-sensitive workloads
• Network I/O Control (NetIOC)
• DirectPath I/O
• Running network latency-sensitive workloads
• Microsoft Virtualization-Based Security (VBS)
• CPU Hot Add
• 4KB native drives
• Selecting virtual network adapters
• The vSphere HTML5 Client
• vSphere web client configuration
• Pair-wise balancing in DRS-enabled clusters
• VMware vSphere update manager
• VMware vSAN performance

Штука эта, очевидно, обязательна к прочтению администраторам vSphere, которые хотят, чтобы у них в инфраструктуре все работало без сбоев и не тормозило.

Несколько интересных моментов из документа:

• Начиная с версии vSphere 6.7, платформа больше не поддерживает программную виртуализацию CPU (только аппаратную).
• vSphere Flash Read Cache (vFRC) может негативно влиять на производительность vMotion.
• Для VVols массив сам обнуляет блоки перед созданием тома, поэтому нет возможности указать тип диска "eager" или "lazy".
• Если вы используете виртуальный сетевой адаптер старой модели с пониженной пропускной способностью, например, Vlance, который показывает в гостевой ОС 10 Мбит/с - это не значит, что он будет работать на этой скорости. Он будет работать на скорости, максимально поддерживаемой физическим оборудованием и хостом ESXi.

Остальные полезные фишки - в документе.

Компания StarWind Software, известная своим лидирующим на рынке решением Virtual SAN для создания отказоустойчивых хранилищ под виртуализацию, обновила свою продуктовую линейку. Теперь она заточена под создание гиперконвергентной инфраструктуры (управление различными аспектами - хранилищами, узлами, сетью - из единой точки) на базе вычислительных узлов, которые одновременно еще и являются узлами кластера хранилищ.

С каждым днем все больше компаний выбирают в качестве основы своей ИТ-инфраструктуры облако в модели IaaS.

Самый важный этап в проектах перехода на облачную модель организации инфраструктуры является планирование, и при выборе IaaS-провайдера необходимо учесть множество факторов, об одном из которых мы хотели бы поговорить сегодня. Речь пойдет о правильном тестировании системы хранения данных...

Таги: IT-Grad, IaaS, Storage, Performance, Cloud

Резервное копирование томов VVols в среде VMware vSphere - немного дополнений.

Мы много пишем о технологии Virtual Volumes (VVols) - например, тут, тут и тут. Она позволяет более гибко подходить к хранению объектов виртуальных машин за счет передачи некоторых функций работы с их данными на сторону хранилищ.

Несмотря на то, что структура хранения виртуальных машин на базе технологии VVols со стороны устройства хранения выглядит по-другому, нежели на классических томах VMFS, резервное копирование для таких ВМ традиционными средствами вполне поддерживается. Об этом мы уже рассказывали тут и вот тут, а сегодня немного дополним эти посты.

Для ПО резервного копирования тома виртуальные машины на томах VVols выглядят аналогично таковым на томах VMFS, поэтому ни схема, ни средства резервного копирования в инфраструктуре VVols не изменяются:

Резервное копирование делается через механизм vSphere APIs for Data Protection (VADP), который создает снапшот на хранилище, чтобы после его создания ПО для бэкапа могло забрать диски с данными ВМ. Отличие тут в том, что в этой схеме снапшот ВМ делает программное обеспечение дискового массива, на сторону которого передаются операции по работе со снапшотами и другие функции.

Кстати, интересная штука - стандартно для виртуальной машины в VMware vSphere можно сделать до 32 снапшотов, хотя VMware рекомендует делать их не более 2-3 в одной цепочке, так как большее количество может привести к различного рода проблемам. А вот с аппаратными снапшотами на томах VVols можно сделать 32 снапшота, и это никаких проблем не повлечет.

На массивах с поддержкой VVols есть поддержка операций "consolidate" и "revert" для снапшотов. В среде VVols они работают по-другому: там есть базовый VMDK, который всегда остается таковым, и куда идет запись, а также вместо записи изменений в redo log там есть read-only файлы снапшотов, которые не подцепляются в зависимую цепочку. При откате снапшота с базовым VMDK никаких длительных последовательных операций не производится (в отличие от VMFS), соответственно все это делать можно безопасно (подробнее - тут).

Также важно помнить, что использование Change Block Tracking (CBT) и vMotion для виртуальных машин на томах VVols может привести к порче данных (подробнее об этом тут). Эта проблема уже решена, но ее исправления будут доступны в следующих релизах vSphere 6.0, 6.5 и 6.7, а пока отключайте DRS для кластеров с виртуальными машинами на томах VVols.

На момент написания статьи VVols поддерживается для работы в трех режимах резервного копирования:

• Резервное копирование за счет монтирования виртуальных дисков (Hot Add backup) - в этом случае к одной ВМ монтируется диск VMDK другой ВМ и происходит его резервное копирование
• Резервное копирование по сети передачи данных (NBD backup) - это обычное резервное копирование ВМ по сети Ethernet, когда снимается снапшот ВМ (команды отдаются хостом ESXi), основной диск передается на бэкап таргет, а потом снапшот применяется к основному диску ("склеивается" с ним) и машина продолжает работать как раньше.
• Защищенное резервное копирование по Ethernet (NBDSSL) - то же самое, что и NBD backup, только с использованием SSL-шифрования при соединении через TCP/IP.

А вот метод без использования сети Ethernet (SAN-to-SAN backup) по-прежнему не поддерживается. Это происходит потому, что для в традиционной инфраструктуре VMFS есть виртуальный хост backup proxy, который говорит виртуальному модулю резервного копирования, какие блоки нужно читать по сети SAN. В среде VVols через VASA API компонент VASA provider на стороне физического сервера или дискового массива пока не может построить физический SAN-путь от хоста ESXi с томом VVols.

VASA provider нуждается в защите (если он реализован в виде виртуальной машины), так как он содержит в себе структуру томов VVols (и маппинги машин к устройствам), и если этот компонент будет потерян, то вы полностью потеряете управление над хранилищами (запущенные машины при этом еще будут работать).

Надо сказать, что вендоры решений с поддержкой VVols, как правило, сами реализуют отказо- и катастрофоустойчивость своих VP (а также их синхронизацию), но необходимо помнить, что это критически важный компонент, и неплохо бы делать его резервное копирование. Помните, что механизм vSphere HA в данном случае вам не помощник - он предназначен для других задач.

Собственно, практически все решения для резервного копирования виртуальных машин на платформе VMware vSphere на сегодняшний день поддерживают VVols:

Иногда бывает, что администратору платформы VMware vSphere требуется выгрузить список всех миграций vMotion виртуальных машин, которые произошли между хостами ESXi в последнее время, а также миграций Storage vMotion между хранилищами.

Для vMotion и SVMotion есть вот такой скрипт от Luc Dekens, который экспортирует миграции за указанное число часов или дней в файл XLS. Запустить его можно такой командой (скрипт точно работает для vSphere 6.5, как пишут здесь):

get-motionhistory -Entity (get-cluster "Cluster 1" | get-vm) -Days 2 | Export-csv -NoTypeInformation -UseCulture E:\VMware\Prod_vMotions.csv

На выходе будет вот такая табличка (обратите внимание, что миграции поделены на пользовательские и системные от DRS/SDRS, а также в поле Type указано, что это - vMotion или SVMotion):

Также ребята из компании Opvisor несколько адаптировали этот скрипт в разрезе миграций хранилищ Storage vMotion для подсчета общего объема миграций и выложили его тут. Работа этого скрипта дает вот такой результат:

Если вы хотите импортировать виртуальный модуль (Virtual Appliance), который идет в формате OVA, на платформу VMware Workstation или Fusion, то иногда при импорте можете получить вот такую ошибку:

Invalid target disk adapter type: pvscsi.

Это все оттого, что платформы Fusion/Workstation пока не поддерживают паравиртуализованный адаптер хранилищ (PVSCSI storage adapter) для формата виртуальных машин OVA (например, в этом формате идет PhotonOS).

Решением этой проблемы является конвертация OVA в формат OVF в помощью ovftool:

ovftool --allowExtraConfig photon-custom-hw13-2.0-304b817.ova photon-custom-hw13-2.0-304b817.ovf

Далее нужно открыть файл формата OVF в обычном текстовом редакторе и найти там строчку:

<rasd:ResourceSubType>VirtualSCSI</rasd:ResourceSubType>

и заменить ее на строчку:

<rasd:ResourceSubType>lsilogic</rasd:ResourceSubType>

После этого нужно удалить созданный файл манифеста (он будет с расширением .mf, наподобие photon-custom-hw13-2.0-304b817.mf), поскольку контрольная сумма OVF-файла изменилась с изменением вами строчки. Ну а затем импортируйте ваш OVF-модуль в среду Workstation/Fusion. Если же вы непременно хотите иметь его в формате OVA, то выполните обратную команду:

ovftool --allowExtraConfig photon-custom-hw13-2.0-304b817.ovf photon-custom-hw13-2.0-304b817.ova

Многие пользователи кластера отказоустойчивости хранилищ VMware vSAN замечали, что в настройках служб кластера есть такая опция "Erase disks before use", которая доступна при шифровании хранилища (vSAN Encryption).

Эта настройка позволяет очистить диск перед использованием шифрования на нем, чтобы соблюсти требования к безопасности хранения и обслуживания данных, например, NIST 800-88 Revision 1, определение "Clear":

Clear applies logical techniques to sanitize data in all user-addressable storage locations for protection against simple non-invasive data recovery techniques; typically applied through the standard Read and Write commands to the storage device, such as by rewriting with a new value or using a menu option to reset the device to the factory state (where rewriting is not supported).

В приложении A приведенного выше документа есть такая таблица (приведены только 2 строки из нее):

Чтобы соблюсти эти гайдлайны, кластер vSAN может вычищать предыдущие данные добавляемого диска перед первым использованием. Но при этом блоки заполняются не нулями или однотипными значениями - ведь это может вызвать сбой механизмов дедупликации и компрессии, поэтому в блоки записываются просто случайные данные.

Ставя галку "Erase disks before use" надо понимать, что процесс заполнения блоков случайными значениями занимает значительное время, которое зависит от типа используемого хранилища и инфраструктуры хранения в целом.

Также важно помнить, что включение vSAN Encryption влечет за собой шифрование только новых создаваемых дисковых объектов и не применяется к существующим на хранилище блокам (то есть их потенциально можно считать с диска, расшифровка их не потребуется). Таким образом, использование vSAN Encryption с настройкой "Erase disks before use" имеет смысл только при добавлении устройств, где ранее существовали данные.

Поэтому:

• Включайте опцию "Erase disks before use", когда:
  • Включаете vSAN Encryption для существующуего vSAN кластера, в котором требуется вычистить свободные блоки.
  • Добавляете хост, который имел ранее данные на локальных дисках, в кластер vSAN.
  • Выполняете операцию rekey для инициации процедуры deep rekey (запрос нового KEK и новых уникальных DEKs для каждого устройства vSAN).
• Не обязательно включать "Erase disks before use", когда:
  • Включаете vSAN Encryption для полностью нового кластера vSAN, в котором ранее не было данных на добавляемых дисках.
  • Добавляете в кластер vSAN хост, у которого на локальных дисках не было чувствительных данных.
  • Выполняете операцию rekey для инициации процедуры shallow rekey (только запрос нового KEK).

В апреле этого года компания VMware выпустила обновленную версию решения для создания отказоустойчивых кластеров хранилищ для виртуальных машин VMware vSAN 6.7. В этом продукте появилось несколько интересных возможностей, но наиболее наглядной стал переход на интерфейс Clarity UI, который позволяет организовать панели и визуальные элементы наиболее удобно для пользователя.

Служба vSAN performance service все еще является опциональной в кластере vSAN, однако уже содержит в себе ряд сервисов, играющих ключевую роль для мониторинга виртуальной инфраструктуры.

На каждом из серверов VMware ESXi служба vSAN performance service развертывается отдельно и позволяет независимо от сервера vCenter собирать данные о производительности кластера и предоставлять их внешним потребителям - CLI, PowerCLI, различным SDK и серверам vCenter:

Такая архитектура позволяет не создавать большой нагрузки на сервер vCenter, который бы в одиночку собирал и обрабатывал эти данные.

Данные о производительности собираются на уровне дисковых объектов, которым назначена определенная политика хранения (Storage Policy). Посмотреть эти объекты можно в разделе vSAN->Virtual Objects:

Так как сервис отслеживания производительности vSAN на хосте ESXi глубоко интегрирован с гипервизором, он позволяет получать метрики для всего стека работы с хранилищем на различных уровнях - виртуальной машины, хоста ESXi и кластера vSAN в целом.

В последней версии диски и дисковые группы были консолидированы в одну категорию, то есть можно посмотреть статистики по группе в целом, а также по отдельному физическому диску. Кроме того, можно смотреть информацию и об устройствах кэширования на хосте (buffer/cache device) в рамках дисковой группы:

В зависимости от того, какой вид просмотра группы или устройства вы выберете, будут доступны те или иные графики производительности. Например, для дисков хранения (capacity devices) будут показаны дополнительные графики "vSAN Layer IOPS" и "vSAN Layer Latency".

Также претерпели изменения разделы "VMkernel Adapters" и "VMkernel Adapters Aggregation" сетевых ресурсов хостов ESXi, которые были объединены в едином представлении Host Network:

Теперь можно выбрать просмотр агрегированных статистик по всем VMkernel адаптерам на хосте, либо выбрать отдельный адаптер. Надо помнить, что статистика по IO в данном разделе - это весь трафик VMkernel, а не только трафик vSAN (например, еще vMotion).

Кстати, интересно, что метрика packet loss, отображаемая как в формате, например, 23%o - это на самом деле не проценты, а так называемое permille-значение. То есть количество потерянных пакетов из одной тысячи (а не из ста, как в случае с процентами). Таким образом, 23%o соответствует значению 2.3% потерянных пакетов.

Еще одно полезное нововведение службы performance service в vSAN 6.7 - это возможность перестраивать размещение графиком в соответствии с разрешением экрана устройства. Например, на небольших устройствах графики будут идти последовательно вниз друг за другом, а на больших экранах показывается вот такой дэшборд:

Ну и последнее приятное улучшение - это возможность выбрать временной отрезок на любом графике и прозуммироваться в этот диапазон. Чтобы вернуться к изначальному представлению, надо нажать Zoom Out:

В графическом интерфейсе по управлению отказоустойчивым кластером VMware vSAN на платформе VMware vSphere отсутствует детальная информация о том, какая машина сколько физического пространства потребляет на уровне своих объектов (VMDK, vSWP и т.п.). Между тем, это может иногда оказаться полезным для администраторов, которые анализируют использование хранилищ и их рост.

Вильям Лам написал полезный PowerCLI-крипт, который позволяет такую статистику вывести - VSANVMDetailedUsage.ps1. Этот скрипт использует VSAN Management API, а в частности метод VsanQueryObjectIdentities() и свойство includeSpaceSummary.

Сценарий работает напрямую с хостом ESXi (поэтому надо предварительно установить переменные $ESXiHostUsername= "пользователь" и $ESXiHostPassword = "пароль"), а в качестве входного параметра для функции Get-VSANVMDetailedUsage надо указать имя кластера vSAN.

Соответственно, использовать скрипт нужно так:

Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster"

В результате вы получите подробную информацию обо всех виртуальных машинах кластера, их дисковых объектах, сколько места они занимают на диске фактически, а также сколько под них зарезервировано:

Кроме того, скрипт можно использовать и для просмотра информации по дисковым объектам конкретной ВМ, например, так:

Get-VSANVMDetailedUsage -Cluster "VSAN-Cluster" -VM "Ubuntu-SourceVM"

Возможно, эта информация скоро появится в графическом интерфейсе следующих версий VMware vSAN.

Не так давно мы писали о том, что большинство вендоров решений для резервного копирования не сделали обновления своих продуктов для поддержки VMware vSphere 6.7. Сегодня компания Veeam восполнила этот пробел со своей стороны и выпустила апдейт Veeam Backup Replication 9.5 Update 3a, который полноценно поддерживает все возможности последней версии платформы виртуализации от VMware.

Давайте посмотрим на полный список новых возможностей этого обновления:

• Поддержка VMware vSphere 6.7.
• Предварительная поддержка VMware vSphere 6.5 Update 2 (будет выпущено еще одно обновление, когда VMware пофиксит баг).
• Поддержка VMware vCloud Director 9.1.
• Поддержка VMware Cloud on AWS версии 1.3.
• Поддержка гостевых ОС Microsoft Windows 10 April 2018 Update и Microsoft Windows Server 1803 в виртуальных машинах, а также систем Hyper-V на базе этой ОС. Также поддерживается и Microsoft System Center Virtual Machine Manager 1801.
• Улучшения производительности в режимах Direct Storage Access (DirectSAN) и Virtual Appliance (Hot Add).
• Сохранение Linux SUID и SGID при операциях "Copy To". Также появилась поддержка томов Btrfs размещенных на томе LVM.
• Задачи резервного копирования Storage snapshot-only для vCloud Director работают для всех поддерживаемых хранилищ (ранее было доступно только для NetApp).
• Улучшения и исправления ошибок для служб Veeam Cloud Connect (подробнее - тут).
• Исправления ошибок.

Полный список всех нововведений Veeam Backup Replication 9.5 Update 3a приведен в Release Notes. Скачать его можно по этой ссылке. Инструкции по обновлению приведены тут.

Компания VMware сделала доступным список часто задаваемых вопросов по обновлению до последних версий платформ виртуализации - VMware vSphere Upgrade FAQ. В данных вопросах рассматривается как процесс обновления, так и дальнейшее функционирование инфраструктуры VMware vSphere 6.5 и 6.7.

Список вопросов по апгрейду на vSphere 6.7 и 6.5 затрагивает следующие темы:

• Deployment Topologies
• Migration
• General Upgrade
• Management Clients
• Licensing
• Interoperable Solutions
• Networking
• Storage
• vCenter Server Appliance (VCSA)

Тем, кто планирует обновление, конечно же, рекомендуется эту страничку почитать. Кстати, помните, что апгрейд с недавно вышедшей версии VMware vSphere 6.5 Update 2 на VMware vSphere 6.7 пока еще не поддерживается.

На сайте проекта VMware Labs появилось второе (со времени выхода VMware vSphere 6.7) обновление HTML5-клиента для управления виртуальной инфраструктурой - VMware vSphere Client 3.39. Напомним, что о прошлых версиях этого тонкого клиента мы писали около месяца назад вот тут.

Давайте посмотрим, что нового появилось в VMware vSphere Client 3.39:

• Полностью реализованная функциональность механизма автоматизированного развертывания хостов Auto Deploy (то же самое, что есть сейчас в vSphere Web Client):
• Software Depots
• Deploy Rules
• Deployed Hosts
• Discovered Hosts
• Configure (настройка самого Auto-Deploy)
• Поддержка бандлов скриптов для Auto-Deploy (теперь это есть только в vSphere Client):
• Просмотр бандлов скриптов в списке всех бандлов
• Возможность загрузить бандл скриптов
• Возможность добавить или изменить правила развертывания с бандлами скриптов
• Новое представление виртуальных коммутаторов на хосте, которое включает в себя диаграммы с топологиями для стандартных виртуальных коммутаторов, а также host proxy switches.
• Улучшенная функциональность для виртуальных сервисов vApp и виртуальных машин в их составе: создание, редактирование, удаление, изменение значений.
• Были улучшены vCenter Extensions.
• Доработаны правила механизма Storage DRS для виртуальных машин - создание, редактирование и удаление.

Скачать VMware vSphere Client 3.39 можно по этой ссылке.

Коллеги из компании NetApp пришлашают наших читателей на конференцию NetApp Directions – главное событие лета в мире управления данными, которое состоится в Москве 17 июля. Участники смогут послушать доклады специалистов NetApp и ее технологических партнёров, подробнее познакомиться с технологическими новинками на стендах выставки, а также узнать о примерах успешного внедрения и обсудить практические вопросы с представителями, партнерами и заказчиками NetApp.

Отдельной темой станет опыт применения решений NetApp в сфере искусственного интеллекта. Взглядом на этот аспект поделится Дмитрий Конягин, руководитель направления профессионального бизнеса NVIDIA.

Октавиан Танаси (SVP ONTAP Software & Systems Group, NetApp) подробнее расскажет о софтверных решениях компании и перспективах развития NetApp в ближайшем будущем. Также перед гостями выступят с докладами представители Cisco и Veeam Software.

Кроме того, на NetApp Directions вы сможете больше узнать о NetApp Cloud Volumes, полностью управляемой облачной файловой СХД, AFF A800, первой корпоративной платформае со сквозным подключением NVMe, обновлённом StorageGRID и других новинках компании.

В этом году партнерами конференции NetApp Directions выступили компании Veeam, Softline, NVIDIA, IT-GRAD, Bull, Brocade, Netwell, Merlion, OCS, Айтеко, ICL Системные технологии, FastLane и другие.

Регистрируйтесь бесплатно по ссылке: https://www.netapp.ru/company/events/netapp-directions-2018-moscow

В начале этого года мы писали про новые возможности платформы виртуализации Citrix XenServer 7.3, бесплатная версия которой была натурально кастрирована членами (sic) продуктовой команды Citrix. В феврале этого года вышел еще XenServer 7.4 (там появилась функция Live Migration для vGPU и поддержка AMD MxGPU), ну а на днях была выпущена обновленная версия XenServer 7.5.

Давайте посмотрим, что нового появилось в XenServer 7.5:

1. Увеличение размера пула XenServer Pool с 16 до 64 хостов.

Это действительно существенное нововведение для тех, кто хочет использовать XenServer в Enterprise-окружениях. Это позволяет обеспечить большую гибкость в кластере, где работает механизм обеспечения высокой доступности, и есть общие хранилища.

2. Возможность создания "тонких" хранилищ (thin provisioning) для iSCSI/FC.

Ранее тонкие диски в репозиториях XenServer можно было использовать только для файловых хранилищ типа LVM Storage Repository. Теперь же средствами экспериментальной возможности для файловой системы Linux GFS2 можно использовать репозитории, размещенные на блочных хранилищах iSCSI или Fibre Channel, и создавать "тонкие" виртуальные диски для машин.

Для больших инсталляций XenApp и XenDesktop на платформе XenServer, которые используют Machine Creation Services (MCS), это позволит экономить массу дискового пространства за счет создания растущих по мере наполнения данными виртуальных дисков.

3. Увеличение максимального размера виртуального диска до 16 ТБ.

За счет использования файловой системы GFS2 в XenServer 7.5 максимальный размер диска виртуальных машин вырос с 2 ТБ до 16 ТБ. Это будет особенно интересно для больших баз данных в ВМ. Пока эта фича также в статусе экспериментальной (как и вся поддержка GFS2).

4. Поддержка проброса USB и экспериментальные функции SR-IOV.

Теперь XenServer 7.5 поддерживает функции проброса устройств USB pass-through, а также функции виртуализации ввода-вывода Network card SR-IOV (пока также в экспериментальном режиме).

Полный список новых возможностей платформы можно узнать из документа "XenServer 7.5 Release Notes", также посмотрите "Quick Start Guide". Скачать XenServer 7.5 можно по этой ссылке.

В конце апреля этого года компания StarWind выпустила обновление лучшего на рынке решения для создания программных iSCSI-хранилищ под виртуализацию - StarWind Virtual SAN. В конце апреля было выпущено большое обновление Virtual SAN v8, а в середине мая был выпущен еще один небольшой апдейт.

Давайте посмотрим, что нового появилось в StarWind Virtual SAN v8 build 12146 и 12166:

• Для модуля Cloud Replication появилась поддержка Backblaze B2 Cloud Storage.
• Для синхронной репликации и режима обслуживания (maintenance mode) события, описанные в Event Log, стали более детализированными. Вот примеры:
  • (id 809) Underlying device response time is longer than expected.
  • (id 824) Partner "%s" request response time is longer than expected.
  • (id 825) Request execution time is longer than expected.
  • (id 821) Maintenance mode is turned ON.
  • (id 822) Maintenance mode is turned OFF.
• Несколько изменено поведение кластера - теперь при ручном отключении двух партнерских HA-устройств на сервере оставшийся узел выпадает в состояние "not synchronized". Также если выпадает HA-устройство, а затем Witness-узел, то при возвращении Wintness-узла в онлайн - работоспособность кластера автоматически восстанавливается.
• Теперь отсутствует интервал в 30 секунд между отправкой email-нотификаций, также можно поменять SMTP-порт.
• Если хранилище создается на устройстве, которое некорректно сообщает о размере физического сектора, StarWind все равно позволяет его создать, но с предупреждением.
• Для управления модулем VTL появилась функциональность StarWindX PowerShell. В составе продукта идут вот эти примеры:
  • \StarWindX\Samples\powershell\CreateVirtualTapeLibrary.ps1
  • \StarWindX\Samples\powershell\InsertVirtualTape.ps1
  • \StarWindX\Samples\powershell\RemoveVirtualTape.ps1
• Добавлен пример PowerShell-сценария для управления трехузловым HA-кластером на базе LSFS:
  • \StarWindX\Samples\powershell\CreateHA_3_LSFS.ps1
• Для LSFS была исправлена проблема на устройствах pre-V8R6 (при заполненности данными более 1,2 ТБ могла произойти потеря данных при рестарте сервиса). Были исправлены и некоторые проблемы апгрейда LSFS с релиза V8R5. Также было улучшено поведение LSFS при высоких нагрузках (изменена процедура дефрагментации).
• В Management Console была добавлена поддержка новой версии продукта StarWind VSA 2.0.
• Было сделано множество исправлений ошибок с HA-устройствами, снапшотами и хранилищами.

Очень рекомендуем текущим пользователям StarWind Virtual SAN v8 накатить это обновление (вот инструкция, как это сделать). Ну а тем, кто еще не развертывал StarWind в своей инфраструктуре - рекомендуем попробовать этот продукт бесплатно. Более подробно о решениях StarWind Software можно почитать в Resource Library.

На сайте проекта kauteetech.github.io есть интересный калькулятор vSAN Effective Capacity для показа распределения емкости отказоустойчивых хранилищ VMware vSAN. Он показывает размещение различных областей данных в общем пространстве хранения, организованных на серверных узлах All-flash (все SSD диски) или гибридной модели (SSD для кэша, HDD для данных):

Это очень простая утилита для самой примерной визуализации расчетов. Напомним, что для точного вычисления всех параметров есть VMware vSAN Sizer (он также умеет рассчитывать необходимое число узлов vSAN).

В качестве исходных параметров для vSAN Effective Capacity могут быть использованы:

• Число узлов кластера (хостов ESXi)
• Число дисковых групп
• Соотношение дисков с данными на группу
• Запас по емкости кластера в процентах
• Затраты на хранение контрольных сумм RAID
• Размер диска с данными
• Тип обеспечения отказоустойчивости FTT (число избыточных копий данных)

Штука интересная, поскольку кроме численных параметров сырой и эффективной емкости, наглядно показывает, сколько от общего объема хранилищ занимает сегмент с данными в определенной конфигурации.

Еще в далеком 2011 году мы писали о средстве VMware I/O Analyzer, которое позволяет сгенерировать нагрузку на хранилища VMware vSphere, а после чего замерить производительность этих хранилищ. Делается это средствами интегрированного фреймворка, который поддерживает распределенную архитектуру - центральный управляющий виртуальный модуль и воркеры (генераторы нагрузки).

В 2014 году это средство еще раз обновилось для поддержки актуальных на тот момент версий ESXi, ну а на днях появилось обновление VMware I/O Analyzer 1.6.2u1, которое поддерживает VMware vSphere 6.5 и более поздние версии, то есть vSphere 6.7.

Напомним основные возможности VMware I/O Analyzer:

• Интегрированный фрейворк для тестирования производительности хранилищ.
• Простая настройка и возможность исполнения тестов на одном или нескольких хостах ESX/ESXi.
• Возможность просмотра результатов производительности как на уровне хоста, так и на уровне гостевой ОС.
• Возможность экспорта данных для последующего анализа.
• Средства "повторения" нагрузки на хранилища путем ее воспроизведения из трейса ввода-вывода.
• Возможность загрузки трейсов ввода-вывода для автоматического извлечения необходимых метрик.
• Графическая визуализация метрик и результатов анализа производительности.

В новой версии I/O Analyzer 1.6.2u1 появились следующие фичи:

• Поддержка последних версий vSphere.
• Обновление протокола до версии OpenSSL 1.0.2o.
• Сценарий для горячего обновления с прошлой версии 1.6.2.
• В прошлой версии 1.6.2 были пофикшены уязвимости Shellshock и Heartbleed.

Скачать VMware I/O Analyzer 1.6.2u1 можно по этой ссылке. Инструкция к данному средству тестирования доступна тут.

Компания VMware сделала доступным интересный документ VMware vSAN PoC Performance Checklist, в котором рассматриваются различные аспекты производительности кластеров хранилищ VMware vSAN, которые пользователи развертывают в рамках PoC (proof of concept).

Сначала в рамках чеклиста нам предлагают прочесть следующие документы:

• VMware vSAN Design and Sizing Guide
• VMware vSAN Network Design Guide
• vSphere 6.5 Performance Best Practices Guide
• VMware vSAN Proof of Concept Guide

Если это не помогло, то далее идут пункты таблицы с набором проверок, которые имеет смысл провести перед тем, как обращаться в техподдержку VMware или искать ответы на форумах. Также нам рекомендуют освоить утилиту HCIBench, которая позволяет провести комплексный тест производительности отказоустойчивых кластеров хранилищ.

Разделы документа:

• "Before you Start" Tasks
• Host Based Tasks after vSAN is Deployed
• Choosing An Appropriate Policy to Test
• Choosing Data Services
• Prepping for the HCIBench Benchmark
• Initial Functional Test -HCIBench Easy Run
• HCI Bench - Further Tuning

Надо сказать, что эти проверки могут оказаться полезными всем тем, кто испытывает проблемы с производительностью vSAN и поиском их причин. Также в онлайн-документе VMware vSAN PoC Performance Checklist есть возможность скачать его в формате PDF. Ну и если ничего не помогло, то всегда есть почта для обращений - vsanperformance@vmware.com.

Недавно я начал своё знакомство с Nutanix и первым делом скачал и опробовал NutanixCmdlets PowerShell Snap-in. Сразу выяснилось, что набор командлетов далеко не полный, и многого не хватает. Тут же созрело решение создать вспомогательный Power-NTNX модуль как в своё время я сделал Vi-Module для VMware. Модуль будет обновляться и пополняться по мере возможности и надобности, и с каждой новой функцией будет выходить статья. Уже сегодня есть задумки на 3-4 функции. И первой функцией будет Wait-NTNXTask.

В последнее время мы много писали о новых возможностях платформы VMware vSphere 6.7, напомним наши последние статьи:

• Новая версия платформы виртуализации VMware vSphere 6.7 доступна для скачивания
• Сравнение максимумов конфигурации VMware vSphere 6.5 и 6.7
• Новые возможности VMware vCenter 6.7 - развертывание vCSA стало опцией по умолчанию
• Как отреагировали вендоры решений резервного копирования виртуальных машин на релиз VMware vSphere 6.7
• Новые возможности VMware vSAN 6.7 в составе vSphere 6.7
• Обновленный VMware Update Manager в vSphere Client 6.7
• Рекомендации по обновлению на VMware vSphere 6.7
• Новые фишки безопасности VMware vSphere 6.7 - поддержка Virtualization Based Security
• Новые возможности технологии Instant Clone в VMware vSphere 6.7

Ну а сегодня расскажем о новых возможностях программных интерфейсов API в vSphere 6.7. В первую очередь надо сказать, что появилось несколько наборов RESTful API, которые были полностью переписаны, чтобы соответствовать современному состоянию виртуальной инфраструктуры vSphere.

1. API виртуальных модулей (Appliance API).

Здесь основные улучшения произошли в сфере резервного копирования и восстановления модулей, а также их обновления. Помимо этого, был улучшен процесс мониторинга процесса бэкапа, и, что главное, появилась возможность запланированного запуска резервного копирования через API:

Кроме этого, теперь есть возможность управления жизненным циклом модуля и его обновлением через API. Здесь доступен полный набор интерфейсов - от предпроверок для проведения обновления, до стэйджинга и накатывания самого апдейта с последующей валидацией.

Многие API виртуальных модулей, которые ранее были доступны как превью, теперь выпущены официально. Среди них: управление службами модуля, изменение сетевой конфигурации и настроек NTP. Также появилась давно ожидаемая фича - питанием виртуального модуля теперь можно управлять через API.

2. Обновления vCenter API.

В интерфейсе vCenter RESTful API появилось более 40 новых методов. Они касаются взаимодействия с гостевыми ОС виртуальных машин, просмотра политик хранилищ Storage Policy Based Management (SPBM), а также управления службами vCenter.

Кроме того, через API теперь доступны операции по управлению жизненным циклом vCenter - развертывание, реконфигурация развернутой топологии, отчет о текущем состоянии Platform Services Controller (PSC) и т.п.

Также появилась возможность и обновлять vCenter через API:

3. Прочие улучшения API.

Помимо перечисленного, были сделаны улучшения в vSphere Web Services (SOAP) API. Появились методы по очистке всех сработавших алармов, функциональность управления виртуальным Trusted Platform Module (TPM), а также механизмом Enhanced vMotion Compatibility (EVC).

Также, как мы писали вот тут, появился новый метод по созданию мгновенного клона ВМ (Instant Clone):

Ну и, наконец, появилась возможность узнать дату и время создания виртуальной машины. Для этого нужно обратиться к свойству createDate объекта VirtualMachineConfigInfo.

Мы много писали о релизе новой версии платформы виртуализации VMware vSphere 6.7 и ее возможностях, а сегодня хотим рассказать про нововведения функции Instant Clone, о которых написал Дункан Эппинг. Напомним, что функция мгновенного клонирования виртуальной машины (ранее известная как VMFork) позволяет очень быстро сделать работающую копию запущенной ВМ на платформе VMware vSphere.

Делается это за счет того, что "на лету" создается клон виртуальной машины (VMX-файл, процесс в памяти), который начинает использовать ту же память (Shared memory) на чтение, что и родительская ВМ. При этом дочерняя ВМ в общую память писать не может, а для записи собственных данных используется выделенная область памяти. Для дисков аналогично - с использованием технологии Copy-on-write в дельта-диск дочерней ВМ пишутся отличия от базового диска родительской ВМ:

Такая схема использования родительской ВМ в VMware vSphere 6.5 требовала, чтобы родительская машина и ее мгновенные клоны находились на одном сервере ESXi. А значит для этих ВМ не поддерживались такие технологии, как vMotion/HA/Storage vMotion и DRS. Между тем, это очень важно для служб тестирования, отделов DevOps и т.п.

Теперь же в VMware vSphere 6.7 появились следующие улучшения Instant Clone:

• Появился простейший публичный API, который позволяет автоматизировать процесс создания и перемещения мгновенных клонов. Он умеет пока не все, но будет развиваться. GUI для этого пока также нет.
• Интеграция с технологиями vSphere для обеспечения доступности виртуальных машин (HA, DRS, vMotion, Storage / XvMotion и т.п.).
• Поддержка двух рабочих процессов создания мгновенных клонов: первый - это последовательное создание клонов в процессе работы родительской виртуальной машины, второй - отпочковывание клонов от "замороженной" родительской ВМ.
• Использование технологии P-Share для дедупликации страниц памяти средствами технологии Transparent Page Sharing (даже когда она отключена на хосте ESXi).
• Теперь отношение родитель-клон не такое тесно связанное, как раньше.

Давайте посмотрим на первый рабочий процесс - создание мгновенных клонов работающей ВМ. Это, например, может пригодиться, когда вы массово тестируете обновление компонентов какого-либо приложения. Обновили первый компонент - сделали несколько клонов для тесткейсов, провели тесты, потом обновили следующий - и снова сделали несколько клонов для тестирования.

Схематично это выглядит вот так:

У родительской ВМ создается дельта-диск, который используется первым мгновенным клоном, потом базовая ВМ несколько меняется за время до создания следующего - и на момент создания нового мгновенного клона будет использоваться уже следующий дельта-диск и так далее. Пока для этого нет визуального интерфейса, но все это можно потестировать через MOB-браузер.

Такая схема имеет недостаток в том, что у родительской ВМ плодятся дельта-диски, что приводит к тому, что быстродействие родительской ВМ замедляется, а сама структура за счет увеличения числа дисков существенно усложняется, что потенциально может привести к различного рода сбоям.

Также в данном случае есть проблема сетевой идентификации - все виртуальные машины, которые рождаются как мгновенные клоны имеют те же настройки IP и MAC-адреса, что и родитель. Чтобы изменить их потребуется выполнить следующие действия:

1. После создания Instant Clone внутри нужно отключить сетевой интерфейс через свойство VirtualEthernetCard->connectable->migrateConnect, устанавливаемое в значение disconnect. Далее нужно задать настройки сетевой идентификации ВМ.
2. Если не хочется менять параметры сетевой идентификации, новые ВМ можно просто запускать в отдельной портгруппе, без выхода во внешнюю сеть во избежание конфликтов IP и MAC-адресов.
3. Внутри мгновенного клона нужно обновить настройки сетевого интерфейса, чтобы гостевая ОС получила новый MAC-адрес. Это можно автоматизировать через Guest Operations API.
4. Снова присоединить виртуальную сетевую карту к ВМ, чтобы новые настройки были применены и машина свободно работала в сети. Для этого нужно установить значение свойства VirtualEthernetCard->connectable->connected в true.

Вторая схема - это "заморозка" родительской ВМ таким образом, что ее CPU перестает исполнять инструкции (для этого используется функция instantclone.freeze в утилите vmware-rpctool). После этого механизм Instant Clone способен создавать связанные клоны этой подмороженной ВМ.

Это позволяет не плодить дельта-диски родительской ВМ (так как ее состояние не изменяется) и достичь унифицированной конфигурации мгновенных клонов:

Такая схема может подойти для масштабирования каких-либо типовых унифицированных нагрузок в виртуальных машинах - например, VDI, хосты с контейнерами, Hadoop-воркеры и так далее.

Поморозка ВМ происходит средствами утилиты vmware-rpctool, которая развертывается в виртуальной машине вместе с VMware Tools.

Также теперь мгновенные клоны существенно меньше привязаны к родительской ВМ, что позволяет использовать их более широко, а сами они называются "parentless".

Ну и напоследок обзорное видео от Дункана, посвященное использованию Instant Clones в платформе VMware vSphere 6.7:

Кроме этого, советуем также почитать вот эту статью Вильяма Лама, посвященную мгновенным клонам.

На днях компания VMware объявила о выпуске обновленной версии платформы виртуализации VMware vSphere 6.7 (она уже доступна для скачивания). Сегодня мы расскажем о новой версии управляющего сервера VMware vCenter 6.7 и его новых возможностях.

Начать надо с того, что виртуальный модуль VMware vCenter Server Appliance (vCSA) 6.7 теперь рекомендован для развертывания по умолчанию, а значит VMware уже окончательно рекомендует перейти на этот вариант средства управления виртуальной инфраструктурой.

1. Средства управления жизненным циклом.

Об этом мы уже упоминали в статье про vSphere 6.7. Теперь vCenter Server Appliance 6.7 позволяет развернуть vCenter Server с внедренным компонентом Embedded PSC и поддержкой Enhanced Linked Mode. Это дает следующие преимущества:

• Теперь для высокой доступности vCSA не нужен балансировщик, и технология vCenter Server High Availability поддерживается нативно.
• Теперь проще развертывать инфраструктуру Single Sign-On Domain.
• Поддержка максимумов масштабирования vSphere.
• Можно делать до 15 развертываний vCSA в рамках одного домена vSphere SSO.
• Уменьшение числа узлов, которые надо обслуживать и поддерживать.

Также в составе vSphere 6.7 есть последняя версия vCenter Server 6.7 for Windows, которая уже не будет доступна в следующих версиях платформы. Теперь при миграции старого vCenter на vCSA есть две опции по импорту исторических данных БД:

• Развертывание и мгновенный импорт данных
• Развертывание и импорт данных в фоновом режиме

При этом показывается примерное время простоя сервисов vCenter во время этих процессов:

Также если вы выбрали импорт данных в бэкграунде, то потом можете поставить этот процесс на паузу. Помимо этого, был улучшен интерфейс процесса миграции, а также появилась возможность выбрать кастомные порты, чтобы не перенастраивать фаервол.

Что касается апгрейда с прошлых версий, то vCenter поддерживает только обновление с vSphere 6.0 и 6.5, а vSphere 5.5 остался в пролете, хотя все еще много пользователей этой версии. Таким клиентам надо будет делать чистую установку или мигрировать сначала на 6.0/6.5 (лучше, все же, ставить заново).

Кстати, помните, что конец поддержки vSphere 5.5 наступает 19 сентября 2018 года.

2. Мониторинг и управление.

В первую очередь надо сказать, что интерфейс инструментария vSphere Appliance Management Interface (VAMI) теперь построен на базе фреймворка Clarity, что делает работу с vCSA простой и приятной:

Теперь при управлении vCSA можно пользоваться отдельным разделом Monitoring для проверки состояния виртуального модуля, а также появилась вкладка Disks, где видны разделы vCSA и их заполненность.

Также появилась вкладка Services, где можно смотреть за состоянием служб vCSA. Кроме этого, были улучшены службы Syslog (теперь можно использовать до трех таргетов), а также Update (теперь можно выбрать патч или апдейт, который будет накатываться). Из VAMI теперь можно отправить патч на стейджинг и потом поставить его, ранее это было доступно только через CLI.

Помимо этого, теперь информация об обновлениях более полная и включает в себя критичность апдейта, требуется ли перезагрузка, что именно внутри и т.п.

Ну и одна из главных ожидаемых возможностей - бэкап сервера vCSA на уровне файлов. Теперь можно задать расписание резервного копирования и сколько резервных копий сохранять:

Помимо бэкапа есть и восстановление, конечно. При этом браузер архивных копий показывает их все, без необходимости искать пути до этих бэкапов.

3. Улучшения vSphere Client.

Теперь в HTML5-клиенте vSphere Client появились обновленные рабочие процессы для следующей функциональности:

• vSphere Update Manager
• Content Library
• vSAN
• Storage Policies
• Host Profiles
• vDS Topology Diagram
• Licensing

Но, поскольку vSphere Client не удалось добить до полной функциональности, VMware выпустила и финальный релиз vSphere Web Client 6.7 на базе технологии Flash. Но обещают, что функционал уже почти одинаковый.

Из нового в vSphere Client - появились фичи Platform Services Controller (PSC) UI (/psc), которыми можно управлять через раздел Administration. Кроме этого, появилась отдельная вкладка Certificate management в разделе Configuration.

4. Утилиты CLI.

Вернулась утилита cmsso-util, которая может делать отчеты по виртуальным модулям vCSA, находящимися в рамках одного SSO-домена. Также можно сравнить 2 домена SSO и выгрузить в JSON-файл различия между этими доменами. Кроме этого, можно мигрировать лицензии, тэги, категории и права доступа из одного домена SSO в другой.

Второе улучшение CLI - это установщик vCSA, который позволяет управлять жизненным циклом этого виртуального модуля. vCenter Server Appliance ISO идет вместе с примерами JSON-шаблонов развертывания. Эти шаблоны можно использовать для унификации развертывания серверов vCenter, накатывая эти JSON в пакетном режиме друг за другом. Это позволяет убедиться в унификации конфигурации всех узлов vCenter в рамках больших инсталляций на нескольких площадках.

Скачать платформу VMware vSphere 6.7, содержащую управляющие компоненты VMware vCenter 6.7 и vCSA 6.7 можно по этой ссылке.

На днях компания VMware выпустила Configuration Maximums Tool - средство, которое позволяет посмотреть максимумы конфигурации платформ виртуализации, виртуальных машин и других решений VMware в различных категориях. На данный момент поддерживаются версии VMware vSphere 6.0, 6.5 и 6.5 Update 1 (кстати о сравнении максимумов 6.5 и 6.0 мы писали вот тут).

По умолчанию мы видим следующие Configuration Maximums, которые можно сворачивать-разворачивать в пределах категории:

• Virtual Machine Maximums
• ESXi Host Maximums (Compute)
• ESXi Host Maximums (Memory)
• ESXi Host Maximums (Storage)
• ESXi Host Maximums (Networking)
• ESXi Host Maximums (Cluster and Resource Pools)
• ESXi Host Maximums (VMDirectPath)
• vCenter Server Maximums
• vCenter Server Maximums (Storage DRS)
• Platform Services Controller
• vCenter Server Extensions (Update Manager)
• vCenter Server Extensions (vRealize Orchestrator)
• VMware vSphere Flash Read Cache
• VMware vSAN
• Virtual Volumes

Также многим будет интересна фича сравнения максимумов различных версий VMware vSphere:

Сравнить можно 2 или 3 версии платформы, а результат выгрузить в XLS-файл, чтобы использовать его в MS Excel.

VMware Configuration Maximums Tool доступен по этой ссылке: https://configmax.vmware.com/.

Мы часто пишем о продукте StarWind Virtual SAN, который позволяет организовать кластеры отказоустойчивых хранилищ на базе серверов для виртуальных машин VMware vSphere и Microsoft Hyper-V. В связи с большим интересом к тому, как именно работает это решение с технической точки зрения, постараемся писать об этом побольше. Сегодня мы расскажем об опциональной файловой системе LSFS (Log-Structured File System), которая повышает производительность операций записи и срок службы накопителей.

У некоторых пользователей VMware vSphere при обновлении серверов VMware ESXi возникает проблема - при выполнении команды "esxcli software vib update" в ответ возникает ошибка "No space left on device", хотя с дисками все в порядке, и на них много свободного места, в чем можно убедиться с помощью команды df -h.

Например, появляется вот такой вывод при попытке обновления:

[InstallationError]

[Errno 28] No space left on device

vibs = VMware_bootbank_esx-base_6.5.0-1.41.7967591

Please refer to the log file for more details.

В то же время вывод df -h говорит, что места на всех разделах достаточно:

Очень редко причина такого поведения оказывается проста - на хосте не хватает файловых объектов inodes, как описано в KB 1007638. Это объекты файловой системы, которых может быть до 640 тысяч на одном томе VMFS. Их используемое количество зависит от числа файлов в файловой системе в данный момент.

Проверить наличие свободных inodes можно командой stat -f /:

На картинке мы видим, что запас их еще весьма большой - они почти не израсходованы. Как правило, указанного лимита достичь очень и очень сложно, поэтому чаще всего упомянутое выше сообщение об ошибке связано совсем с другим. Но если вы все же достигли этого лимита, решение тут несложное - удалить какое-то число файлов с ESXi.

Например, можно найти лог-файлы и прочие файлы на хосте ESXi размером более 50 МБ, которые находятся НЕ на томах VMFS (чтобы не задеть логи ВМ), можно следующей командой:

find / -path "/vmfs" -prune -o -type f -size +50000k -exec ls -l '{}' \;

По итогу будет сгенерирован список преимущественно локальных файлов, который будет содержать ISO-образы, большие лог-файлы и т.п., которые уже скорее всего не нужны, и их можно удалить (а лучше переместить на какое-нибудь хранилище в целях архивирования). Также рекомендуем почитать KB 1008643, которая как раз посвящена удалению файлов в целях высвобождения объектов inodes.

Между тем, в случае появления приведенной в начале статьи ошибки о недостатке свободного места очень вероятно, что хост ESXi не может аллоцировать достаточно оперативной памяти (RAM) для проведения обновления. В этом случае вам просто надо включить ESXi system swap, который будет размещен на одном из датасторов, куда будут сбрасываться страницы оперативной памяти при недостатке памяти во время обновления.

Сделать это можно, зайдя в раздел Manage > Settings > System Swap, после чего нажав Edit...:

Выберите датастор и нажмите Ok. Также это можно сделать с помощью функционала Host Profiles:

После выбора датастора для системного свопа обновите хост ESXi и перезагрузите его.

За последнее время у компании VMware вышло несколько материалов по продукту для создания отказоустойчивых кластеров хранилищ VMware vSAN 6.6.

Во-первых, вышло хорошее обзорное видео:

Во-вторых, был опубликован полезный технический документ "VMware vSAN 6.6 Technical Overview", где с технической точки зрения рассматриваются возможности vSAN 6.6:

Ну и, в-третих, вышла лабораторная работа (Hands-On Lab) для администраторов - vSAN 6.6 – Getting Started Hands-on Lab, пройдя которую можно узнать основные возможности продукта и обучиться приемам работы с кластерами vSAN:

Многие из вас иногда хотят получить так называемый "Support Bundle", содержащий лог-файлы, диагностическую информацию и метрики производительности, который помогает решать проблемы в инфраструктуры VMware vSphere. В первую очередь, этот бандл нужен для предоставления службе технической поддержки VMware GSS (Global Support Services) информации о конфигурации виртуальной среды, чтобы она могла решать возникающие у клиентов проблемы в рамках обращений (тикетов) в техподдержку.

Но, кроме этого, данный бандл может пригодиться и вам, как, например, описано в этой статье для анализа причин "розового экрана смерти" и прочих аномалий.

Давайте рассмотрим основные способы получения support bundle как для серверов VMware vCenter (для Windows или виртуального модуля vCenter Server Appliance, vCSA), так и для серверов VMware ESXi. Кстати, надо учитывать, что после экспорта бандла с логами результирующий файл будет размером 30-300 МБ в зависимости от того, что вы туда включите, а также как давно и интенсивно менялась конфигурация виртуальной среды.

Получение Support Bundle для серверов vCenter

Самый простой способ получить саппорт бандл - это выгрузить его с помощью vSphere Web Client. Для этого нужно выбрать сервер vCenter в иерархии инвентори и выбрать пункт Export System Logs (работает как для обычного vCenter, так и для vCSA):

Далее вам предложат, какие разделы нужно включить в сгенерированный бандл логов:

Если вы используете vCSA, то можно получить логи через веб-интерфейс. Для этого надо перейти по адресу:

https://<ip vcsa>/appliance/support-bundle

И далее ввести логин и пароль root от виртуального модуля vCSA.

После этого support bundle будет сгенерирован и загружен через ваш браузер.

Кроме этого, есть способ получить логи vCSA из Linux-системы с помощью утилиты curl. Для этого нужно выполнить следующую команду:

curl -k -u root -o support-bundle.tar.gz -O https://<ip vcsa>/applmgmt/support-bundle

После того, как вы скачаете этот бандл, нужно будет разархивировать его командой:

tar -zxvf support-bundle.tar.gz

Также Support Bundle можно получить с помощью PowerCLI. Для этого нужно соединиться с сервером vCenter:

Connect-VIServer -Server HostnameOrIPAddress

И далее использовать следующую команду:

Get-Log -Bundle -DestinationPath c:\Storage\Location\

Более подробная информация об этом приведена в KB 1027932. Там же, кстати, есть информация и о том, как искать в файлах логов с помощью PowerCLI:

Get-VMHost HostNameOrIP | Get-Log LogName | Select -expand Entries | Select-String SearchTerm | More

Здесь SearchTerm - это строка поиска, а LogName - это один из следующих логов:

• hostd
• vpxa
• messages
• vmkernel
• vmksummary
• vmkwarning

Получение Support Bundle для серверов ESXi

По аналогии с получением бандла для сервера VMware vCenter или vCSA, в vSphere Client можно выбрать сервер VMware ESXi и выбрать для него пункт "Export System Logs":

Также можно сгенерировать Support Bundle через тонкий клиент для управления серверами VMware ESXi - Embedded Host Client (он же - просто веб-интерфейс для управления хостами ESXi). Он доступен при соединении с хостом ESXi по ссылке:

https://<ip esxi>/ui

Для генерации саппорт бандла нужно выбрать пункт "Generate support bundle" из контекстного меню хоста:

Помимо этого, его можно сгенерировать и в консоли ESXi. Для этого используется команда vm-support без параметров (подробнее об этом написано в KB 1010705). Чтобы получить Support Bundle нужно в консоли ESXi выполнить следующую команду:

# vm-support

Надо отметить, что у утилиты есть множество разных параметров:

Аналогично получению бандла для vCenter, через PowerCLI можно получить и бандл для хоста ESXi. Соединяемся с хостом, забираем бандл и складываем его в нужную папку:

Get-VMHost HostNameOrIP | Get-Log -Bundle -DestinationPath c:\Storage\Location\

Для тех, кто хочет узнать, что же находится внутри Support Bundle, мы рекомендуем статью "What's Inside an ESXi vm-support Bundle?".

Если вы зайдете на страницу поддерживаемых устройств ввода-вывода (I/O Devices) в списке VMware Hardware Compatibility List (HCL), то в правой колонке увидите там следующие параметры:

• VID (Vendor ID)
• DID (Device ID)
• SVID (Sub-Vendor ID)
• SSID (Sub-Device ID)

Все эти категории там не просто так - это очень удобный способ проверить совместимость вашего устройства ввода-вывода (сетевая карта, HBA-адаптер, SCSI-контроллер, USB-контроллер, и т.п.) с платформой VMware vSphere / ESXi и другими продуктами.

Например, если вы хотите узнать эти параметры для сетевой карты, то можно вывести список PCI-устройств командой vmkchdev, отфильтровав их с помощью grep по свойству vmnic (сетевой адаптер):

vmkchdev -l | grep vmnic

Далее вы увидите подобный вывод:

[dpasek@esx01:~] vmkchdev -l | grep vmnic

0000:02:00.0 14e4:1657 103c:22be vmkernel vmnic0

0000:02:00.1 14e4:1657 103c:22be vmkernel vmnic1

0000:02:00.2 14e4:1657 103c:22be vmkernel vmnic2

0000:02:00.3 14e4:1657 103c:22be vmkernel vmnic3

0000:05:00.0 14e4:168e 103c:339d vmkernel vmnic4

0000:05:00.1 14e4:168e 103c:339d vmkernel vmnic5

0000:88:00.0 14e4:168e 103c:339d vmkernel vmnic6

0000:88:00.1 14e4:168e 103c:339d vmkernel vmnic7

Здесь вот этот участок - 14e4:1657 103c:22be - для адаптера vmnic0 позволяет разложить его на 4 приведенных выше параметра:

• VID = 14e4
• DID = 1657
• SVID = 103c
• SSID = 22be

После этого вы просто вбиваете эти параметры в VMware HCL для I/O-устройств в правую колонку и смотрите, совместима ли данная сетевая карта с данной версией VMware ESXi.

Если вы отфильтруете вывод по строчке vmhba, то можете получить локальные SCSI-контроллеры или HBA-адаптеры, которые также можно проверить аналогичным образом.

На днях компания VMware выпустила мажорное обновление своего основного интерфейса для управления виртуальной инфраструктурой с помощью скриптов - PowerCLI 10.0.0. О предварительных возможностях этого релиза мы уже писали вот тут.

Давайте посмотрим, что нового появилось в PowerCLI 10:

1. Настоящая (почти) мульти-платформенность.

Теперь PowerCLI доступен для систем Mac OS и Linux. Единственное требование - у вас должен быть развернут PowerShell Core 6.0.

Установка очень проста:

Install-Module -Name VMware.PowerCLI -Scope CurrentUser

На данный момент для Мака и Linux поддерживаются только следующие модули:

• VMware.VimAutomation.Common
• VMware.VimAutomation.Sdk
• VMware.VimAutomation.Core
• VMware.VimAutomation.Cis.Core
• VMware.VimAutomation.Vds
• VMware.VimAutomation.Storage
• VMware.VimAutomation.StorageUtility

Со временем эта поддержка будет расширена.

2. Изменения обработки сертификатов.

Теперь при соединении с сервером vCenter или ESXi через командлет Connect-VIServer с невалидным сертификатом (например, самоподписанным) PowerCLI выдаст уже не предупреждение, как в прошлых релизах, а ошибку. Чтобы изменить это поведение, вам потребуется использовать командлет Set-PowerCLIConfiguration:

Set-PowerCLIConfiguration -InvalidCertificateAction Ignore

Он принимает следующие значения:

• Fail
• Warn
• Ignore
• Prompt
• Unset

3. Устаревшие и исключенные командлеты.

Теперь в PowerCLI 10 пять командлетов модуля VMware.VimAutomation.Core были исключены:

• Get-VMGuestNetworkInterface
• Set-VMGuestNetworkInterface
• Get-VMGuestRoute
• New-VMGuestRoute
• Remove-VMGuestRoute

Они были заменены командлетом Invoke-VMScript. Вот пример использования этого командлета:

$ipAddr = "192.168.10.25"

$subMask = "255.255.255.0"

$gw = "192.168.10.1"

$netsh = "c:\windows\system32\netsh.exe interface ip set address ""Local Area Connection"" static $ipAddr $subMask $gw 1"

Invoke-VMScript -VM $VM -GuestCredential $creds -ScriptType bat -ScriptText $netsh

Также теперь не актуально свойство "Client", вместо этого предлагается использовать объект ServiceInstance.

Помимо этого в PowerCLI 10 было пофикшено несколько важных багов на базе фидбэка от сообщества разработчиков. Полный список изменений доступен в VMware PowerCLI Change Log. Более детальная информация об обновлении приведена в документах VMware PowerCLI 10.0.0 User’s Guide и VMware PowerCLI 10.0.0 Cmdlet Reference.

Напомним, что апдейт модулей PowerCLI теперь очень простой:

Update-Module VMware.PowerCLI